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Bi-Directional Programming System/Method For Program Development 
Technical Field 

[001] The present invention relates to a new type of system or method for 
5 developing programs (i.e. software applications), and in particular, to a bi- 
directional programming system or method for assisting a user/programmer to 
develop computer programs. 

Background Art 

10 [002] The concept of describing programs as flowcharts has been used since the 
invention of structured programming languages. Originally, these flowcharts 
were simply drawn on paper to reflect the design that the programmer intended to 
follow when implementing the program. More recently, flowchart drawing 
applications have been created thereby allowing a programmer to create digital 

15 documentation for their program, prior to implementation. 



[003] The basic flowchart element in such a drawing application is described as 
an abstract data type, or class. These drawing applications have generally been 
implemented using the following basic algorithm: 

20 struct Element { 

ElementType type; 

Rect coords; 

ElementPtr prev; 

ElementPtr next; 
25 VoidPtr userData; 

String description; 

String comment; 

}: 

30 Where ElementType is defined as: 

enum ElementType { 

StartFlowchart, EndBlock. CallableStatement, IfClause. 

ElseClause, SwitcliClause, CaseClause, StartRepeat 
35 StartWhile, StartFor • 

}: 



1 
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[004] The flowchart elements are constructed in a doubly linked list, with the 
option of an alternate link to represent an "else" condition. The element type 
defines the drawing algorithm necessary to create any given flowchart element. A 
flowchart data type can now be constructed by building a container to hold an 
5 ordered collection of flowchart elements. 

[005] Using this system, it is possible to provide an abstract view of some 
programming problems. However, in order to provide a more detailed 
implementation of the actual program being developed, a programming syntax 
10 (code) is used, and is compiled into a machine code format. 

[006] A computer system understands instructions provided to it as binary 
numbers, where each given binary number represents an instruction, and each 
such instruction is of a given length, with the binary numbers following the 

15 instruction being the parameters to the instruction. It is unusual and difficult for 
people to understand or program a computer in binary code. For this reason, high 
level languages were developed. High level languages aim to allow people to 
program computers in a language that more closely mimics the English language. 
Unfortunately, the English language cannot be expressed mathematically, and 

20 furthermore, contains enough contradictions in meaning that a computer cannot 
possibly be expected to understand common English language. So, just as with 
spoken/written languages, computer languages utilise a system of grammar. The 
prerequisite for any given computer language is that it is "parsable" (i.e. a 
computer algorithm can be developed to represent the meaning of the language in 

25 mathematical terms). 



[007] The flowchart illustrated in figure 1 (prior art) describes a presently known 
basic parsing algorithm for converting any abstract parsable language (syntactic 
code) to an intermediary form (byte code) that can then be converted to machine 
30 code (binary code). 

2 
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[008] In the field of program or software application development, programmers 
have historically used a text-based programming language (code) to pass 
commands to a computer. This code is terse and often difficult to understand. 
Typing code can be an error-prone and tedious exercise. In an attempt to 

5 somewhat automate the task of coding, several development companies have 
designed various automation solutions based on using pre-written templates or on 
using "scripts", which are easier to write and which translate behind the scenes to 
code. The most outstanding achievement of companies involved in these 
endeavours was to succeed in creating a system which enabled programmers to 

10 build a user interface (UI) (the screens a user sees) by "drag and drop" visual 
methods. Code could then be automatically generated from the visual interface 
created by the "drag and drop'* methods. 

[009] Presently, however, once the user interface is constructed, it is still 
15 necessary to type further code to actually make the program (i.e. the software 
application) do something other than act as a user interface. This part of 
programming is often referred to as "back-end logic building". 

[010] It is presently known to provide a system for developing a user interface 
20 whereby a programmer is enabled to not only build a visual user interface and 

generate code from it, but also to then modify or add to the code and have the 

changes or additions reflected in the visual representation of the user interface. 

This is often referred to as "round-trip engineering" or 'n)i-directional 

programming". For example, Microsoft Corp. conmiercialised such a concept in 
25 the product known as Visual Basic. However, it is most important to understand 

that such presently known technologies apply only to the construction of a user 

interface and not to back-end logic building. 

[Oil] As with most devices we buy, computer User Interfaces represent a static 
30 state within the machine or programme. Therefore, each interface within a 
program is representable as a static image. In the simplest case, it would be quite 
easy to represent program interfaces as a series of bitmap pictures, which the 
operating system is able to divide into the appropriate sections based on the 
coordinates of the mouse at the t^me an event occurred. However, this would 
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incur a very significant amount of CPU time. To overcome this, an interface is 
defined as components which have a static (graphical part) and a dynamic (logic) 
part. For example, a button could take on many forms graphically, but our main 
interest in the button is when it is pressed, or released. This is known as an event. 

[012] A GUI designer such as that used by Visual Basic or Delphi, cannot 
remember, from one session to the next, which event a button is supposed to 
execute when it is pressed, or the position or dimensions of the button. To 
facilitate this, a file is written to disk which contains 'hints' to the IDE as to how 
to draw a button, and what should happen if it is pressed. This is known as a 
script. Systems such as Visual Basic and Delphi, contain their own proprietary 
scripts for this purpose. However, there are standard script definitions available. 
Some of the more well known ones are HTML, XML and Postscript. Note, that 
the layman's term ^scripting languages' is not used here, as the scripts generally 
do not represent a parsable language. In situations where the script is parsable, 
there is generally no concept of timing available (for example, HTML has no 
If/If-Blse or Loop constructs available etc). 

[013] US Patent No. 5,911,070 (Solton et al) discloses a development system 
with visual designer tools for generating and modifying program code. A user 
employs the visual designer tools to visually create an application program and 
generate a source file. The user can proceed to edit the source file with a text 
editor and then return to the visual designer tools at any time to edit a form 
visually. The user can use both techniques interchangeably, changes which occur 
in the visual designer tools are reflected in the generated source code and vice a 
versa. However, Solton et al. is only directed to the construction of a user 
interface and does not disclose a general means for round-trip software 
engineering as it more broadly relates to back-end logic building of a complete 
and functional program. 

[014] In contrast, however, a true visual programming language must by 
definition be able to represent a ^program* visually. A static script contains 
insufficient data to model the final solution. Graphical user interface development 
tools, like those provided with ^lany modem compilers including Microsoft 
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Visual C++, include highly visual components, but they are more graphics 
applications and template generators than actual progratnming languages. 

[015] Several types of Visual Programming Language (VPL) exist, as a result of 
multiple attempts to resolve the specific problems presented in trying to represent 
a series of time-sequenced events and actions visually. The various types include: 

1. Purely visual languages: those which create a graphical 

environment in which the entire development and testing process is 
performed, and require the compilation of the program within the visual 
environment. These systems use proprietary "objects", or blocks of pre- 
written code represented by graphical elements. The programmer assembles 
the application by arranging the objects in a sequence. Each object calls its 
related code. The code is not modifiable by the programmer in any way, 
15 and the quality of the compiled application is wholly determined by the 

quaUty of the pre- written code objects and the ability of the programmer to 
select and assemble the objects in the appropriate sequence. 



10 



2. Hybrid text/graphics systems, which generate code from graphical 
20 diagrams. 

3. Programming-by-example systems, in which the programmer 
creates and manipulates graphical objects to "teach" the system how to 
perform a task. 



25 



30 



4. Constraint-oriented systemsj used for simulation design, in which 
the programmer models physical objects as objects in the visual 
environment which are subject to constraints designed to mimic the 
behaviour of natural laws, like gravity. 

5. Forms based systems, broadly based on spreadsheet concepts, 
which represent programming as altering a group of interconnecting cells 
over time to allow the programmer to visualise the execution of the 
program as a sequence of different cell states. 
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[016] The VPL systems listed above fall into one of two categories: 

1. Stating modelling (i.e. "forms based*' visual languages such as 
Visual Basic), which use graphical objects only to represent static states 
5 within the program, and therefore require the interspersion of a text based 

language in order to provide run-time activity. These languages do not 
attempt to facilitate the use of graphical elements to represent actions 
which occur in real-time. 

10 2. Specialised modelling tools (eg. Sketchpad, Thinglab, ARK, etc), 

which provide 'canned code' style graphical objects to represent constants 
within our physical environment. As all fields of science contain absolute 
constants, this premise could be used to provide a modelling environment 
for many situations. Another example is tools such as Rational Rose, which 

15 use the same logic to model business processes/logic. As above, because 

the graphical elements are modelling static or constant states, the 
'program' logic must be built using conventional code. 

[017] The graphical view for existing VPL's is not parsable. Hence, no presently 
20 known system truly provides round-trip engineering or bi-directional 
programming for back-end logic building of a general program. 

[018] This identifies a need to provide a new system or method for facilitating 
round-trip software engineering using flowcharts for use in back-end logic 
25 building of a program. This also identifies a need to provide a new system or 
method for a bi-directional programming system or method for assisting a 
programmer to fully develop a program which is not only a user interface. This 
also identifies a need to provide a new system or method for a bi-directional 
programming system or method where the graphical or visual view is parsable. 

30 

Disclosure Of Invention 

[019] In a broad form, the present invention seeks to provide a new system or 
method for facilitating round-trip software engineering utilising a visual 
representation for use in the bacl^ end logic building of programs. In a further 
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broad form, the present invention seeks to provide a system or method to 
facilitate back-end programming by providing that (a) editing at a source code 
level is automatically interpreted as edits in a flowchart representation which is 
correspondingly updated, and/or (b) existing code for back-end logic building can 
5 be read into a flowchart representation. This provides a means for a programmer 
to modify or add to back-end source code, as opposed to simply user interface 
code, which can then be automatically converted to a visual flowchart 
representation. 

10 [020] The present invention also seeks to provide a bi-directional programming 
system to allow a programmer to enter source level instructions into a computer 
system via either a visual (or graphic) language interface or a traditional syntactic 
level interface. Irrespective of which means is used to initially describe the 
program, a corresponding "view" of the program (visual or syntax) can be 

15 generated. Changes to the program can be made at either level, allowing the 
regeneration of the corresponding view (visual or syntax) to reflect the changes. 
For example, should the original program be described in a visual or graphical 
format, then a program with the same meaning can be generated in the 
corresponding syntax level format. Similarly, if a programmer wishes to make 

20 changes to this syntax level, then the equivalent version of the program can be 
regenerated in the visual view to reflect the changes. 

[021] The present invention provides , a round-trip software development 
application for use in back-end logic building of programs in which the graphical 
25 view of the program is parsable. Because the graphical view is parsable, the data 
can be readily modelled using mathematics. This means that any other 
programming language that can describe the mathematical meaning can also be 
used for the graphical view. This way, the round-trip is facilitated by simply 
changing the current view of the program data. 

30 

[022] In a particular embodiment of the invention, the underlying syntax level 
language used is the Java programming language, and the visual or graphic 
language is described by way of a flowchart diagram, structure diagram, work- 
flow diagram, parse tree or the T'ce. Preferably, flowchart diagrams, structure 
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diagrams, work-flow diagrams, or the like, are used to convey the visual view as 
most programmers are familiar with first describing a program in this manner 
prior to commencing the writing of source c^de. Similarly, the Java language may 
be used for the syntax view for its platftjfm independence, hence preventing the 

5 program from being restricted to any specific operating system. In one 
embodiment of the invention, the byte-code language includes constructs selected 
from the following set: Assignment; Method Call; If Expression; If/Else 
Expression; For Loop; Repeat Clause; Do/While Clause; Switch/Case Expression; 
Synchronized; Try/Catch/Finally; End Block; or any other higher level language 

10 constructs 

[023] In a broad form of the present invention there is provided a method of 
developing a computer program using bi-directional programming means, the 
method including: (1) utilising a visual representation of the program that can be 

15 parsed and edited; and, (2) utilising a syntax code representation of the program 
that can be parsed and edited; (3) converting between the visual representation 
and the syntax code representation by converting the visual representation and the 
syntax code representation into byte-code representations and comparing the byte- 
code representations; wherein, edits in the visual representation are reflected in 

20 the syntax code representation, and vice versa, and the bi-directional 
programming means can be used to build back-end logic for the computer 
program. 

[024] Preferably, the visual representation is a flowchart or structure diagram, 
25 and the visual representation includes an extended flowchart element construct. In 
a particular form, the extended flowchart element construct includes at least: a 
callable statement mapping to a syntax language function call; a condition type 
clause having a condition part; and, a variable. 

30 [025] In a further broad form of the present invention there is provided a system 
for providing bi-directional programming means for developing a computer 
program, the system characterised by: (1) a visual representation of the program 
that can be parsed and edited; (2) a syntax code representation of the program that 
can be parsed and edited; (3) a prc^jessor to convert the visual representation to a 
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byte-code representation and then convert the byte-code representation to the 
syntax code representation, or, to convert the syntax code representation to a 
byte-code representation and then convert the byte-code representation to the 
visual representation; wherein, edits in the visual representation are reflected in 
the syntax code representation, and vice versa, and the bi-directional 
programming means can be used to build back-end logic for the computer 
program. 



[026] In still a further broad form of the present invention there is provided a 
computer program product for use in developing an application program, said 
computer program product providing bi-directional programming means and 
comprising: (1) means to display a visual representation of the program that can 
be parsed and edited; (2) means to display a syntax code representation of the 
program that can be parsed and edited; (3) means to convert between the visual 
representation and the syntax code representation by converting the visual 
representation and the syntax code representation into byte-code representations 
and comparing the byte-code representations; wherein, edits in the visual 
representation are reflected in the syntax code representation, and vice versa, and 
the computer program product can be used to build back-end logic for the 
application program. 

[027] In a possible form of the present invention, the visual representation 
contains an extended element construct and includes primary native language 
semantics selected from the set of: a callable statement mapping to a syntax 
language function call; any other statement mapping to a syntax language 
assignment statement; a condition type clause having a condition part; a 
compound statement; error or exception handling; and/or, one or more variables. 
In a further form, the extended element construct contains a generic data structure 
for the visual representation including a start element, an end element and a 
means of representing a symbol table. In still a further form, the extended element 
consti-uct contains a generic data sti-uctiire for the representation of a collection of 
symbols or a symbol table. In yet still a further form, the extended element 
construct contains a generic data structure for tiie representation of an individual 
symbol. In still yet a further for^i. the extended element construct contains a 
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generic data structure for the representation of an individual node of the visual 
representation. 

Brief description Of Figures 
5 [028] The present invention should become apparent from the following 
description, which is given by way of example only, of a preferred but non- 
limiting embodiment thereof, described in connection with the accompanying 
figures, wherein: 



10 [029] Figure 1 (prior art) illustrates a traditional 'top-down' parsing algorithm; 
[030] Figure 2 illustrates a schematic showing flowchart to code steps; 
[031] Figure 3 illustrates an aspect of the invention showing the complete round- 
trip or bi-directional cycle; 
[032] Figure 4 illustrates an example of an embodiment of the invention in use - 
15 showing an initial flowchart representation; 

[033] Figure 5 illustrates an example of an embodiment of the invention in use - 

showing the generated code; 
[034] Figure 6 illustrates an example of an embodiment of the invention in use - 
showing amendments made by a programmer to the code; 
20 [035] Figure 7 illustrates an example of an embodiment of the invention in use - 
showing the byte-code conversion; 
[036] Figure 8 illustrates an example of an embodiment of the invention in use - 

showing the updated equivalent flowchart representation; 
[037] Figure 9 illustrates an example of an embodiment of the invention in use - 
25 showing the code generated from the updated flowchart; 

[038] Figure 10 illustrates a means of embodying particular forms of the 
invention; 

[039] Figure 1 1 illustrates an example parse tree; 
[040] Figure 12 illustrates the parse tree corresponding to figure 6; 
[041] Figure 13 illustrates the parse tree corresponding to figure 9. 

Modes For Carrying Out The Invention . 

[042] The present invention provides a new bi-directional programming system 

or method for assisting a programmer to develop programs. 

10 



30 
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Preferred einbodiment 

[043] By forcing a controlled structure to be followed for the input of 
information, a flowchart diagram, structure diagram, work-flow diagram or the 

5 like allows a program to be described in a manner that more closely resembles 
either the English language, or whatever natural language a programmer desires to 
work with. However, in order to maintain a productive work environment, it is 
necessary to allow the programmer to continue to work in a familiar manner. 
Hence, the need for a bi-directional prograroming language allowing the 

10 programmer to also enter code, 

[044] Where the traditional means of describing a flowchart algorithmically is 
generally sufficient for docxmienting, and even in some cases generating function 
prototypes (headers), these traditional means do not provide sufficient 
15 information for generating a complete code based representation of an algorithm. 
However, by adding certain information to the flowchart element construct (over 
that which is presently known as discussed in the prior art section), a more 
complete meaning can be created. 

20 [045] Firstly, the concept of a callable statement is given an index, mapping to a 
syntax language function call, and any of the five condition type clauses (eg. 
IfClause, ElseClause,...) is given a condition part. In addition, the concept of a 
variable is introduced, with the created variables given an index from 0...n. 
Where n represents the total nxmiber of created variables, minus one. The 

25 flowchart description now contains both the collection of flowchart elements, and 
a collection of variables or symbols, the Symbol Table. 

[046] This extended flowchart element construct is indicated below: 

30 struct Element { 

ElementType type; 

Rect coords; 

ElementPtr next; 

ElementPtr prev; 
35 VoidPtr userData; 

String description; 



wo 2004/012082 



PCT/AU2003/000937 



String comment; 

}; 

Struct Flowchart { 
5 ElementPtr StartElement; 

ElementPtr EndElement; 
SymbolTable symbols; 

}; 

10 struct SymbolTable { 

Integer symbolCount; 
SymbolPtr firstSymbol; 
SymbolPtr lastSymbol; 

}; 

15 

Struct Symbol { 

String name; 
Typeldentifier type; 
String byteCodeRepresentation; 
20 SymbolPtr next; 

SymbolPtr prev; 

}: 



25 [047] In a preferred, but non-limiting, embodiment the remaining programming 
constructs then conform to the following rules: 

1. A StartFlowchart clause can be followed by any other clause, or an 
EndBlock. 

2. A CaseClause must always follow either a SwitchClause or another 
30 CaseClause. 

3. A CaseClause may be followed by either another CaseClause (the empty 
case), one or more statements, or an EndBlock clause. 

4. An If Clause must contain a condition part. 

5. An If Clause must be followed by either any other clause except a 
35 StartFlowchart clause, or an EndBlock. 

6. A Condition is defined as "statement; mathematic-condition; statement". 

7. A Statement is defined as a Variable or ComplexStatement, where a 
ComplexStatement is a combination of CallableStatements and Variables, 
representing a formula that is solvable to a primitive value. In this context. 
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a primitive is defined as either an Integer, a Decimal Number, or a String 
of characters. 

8, Both statements in a condition, must resolve to equivalent primitive 
types. 

5 9. All other conditional constructs (RepeatClause^ WhileClausBy 

ForClause) must follow the same set of rules. 

10. A ForClause must be followed by two conditional clauses, a start 
condition and an end condition. Furthermore, the end condition of a 
ForClause must be followed by a Statement that resolves to an integer 
10 value, to increment the loop counter on each iteration. 



[048] Throughout our daily lives, most everything we do can be broken down 
into three distinct categories — Problems; Decisions; and Actions. The ^problems' 
usually arise as a result of a previous action. In programming, this is called an 
15 'event'. The way in which we react to an event, is known as a 'method* or 
'procedure'. Sometimes, a procedure, or part thereof, will need to be repeated a 
number of times, in order to extract the desired result. This is known as a 'loop', 

[049] A decision can be described as either: 

20 If (some condition is true), then execute an action. End. OR 

If (some condition is true), then execute action A, else execute action B. 
End. 

By allowing the nesting of these constructs, very complex decisions can be 
represented. 

25 

[050] The final construct required by a prograiimier is called an 'assignment'. 
This is the means by which a programmer can insert into a program, a 
mathematical formula based on known and unknown quantities. The composition 
of Assignments, Conditions, Loops and Procedures/Methods to arrive at a partial 
30 solution to the original problem, is known as an algorithm. A program is then 

13 
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created by analysing the original problem, breaking it down into a number of 
component problems, defining algorithms for each of these small problems, then 
assembling the algorithms into a single unit to solve the original problem. 

5 [051] Using these basic rules, it is possible to describe a flowchart using a string 
of integer values, otherwise known as byte-code. As referred to for figure 1, 
byte-code is the intermediary language used to attempt to describe a program 
when converting syntax level code (source code) to machine code. If there is an 
error at this b)rte-code stage, then the compiler can report an error to the 

10 programmer as a "syntax error", and the compilation will be aborted. 

[052] By representing the program at this byte-code level, a "view" can be 
created that describes the program in a manner that humans can more readily 
understand. The flowchart is considered the most desirable view to use, as this is 
15 readily understood by programmers and non-programmers alike. 

[053] The final stages of the traditional compiling process can then be used to 
convert the code into a machine readable instruction set, however, this is not the 
purpose of the present invention. Rather,, the present invention is concerned, in 
20 part, with converting the flowchart byte-code back to the equivalent syntax level 
code for manipulation by a programmer. 

[054] Referring to figure 2, the illustrated flowchart reverses the appropriate 
compilation steps, to convert the flowchart byte-code back to syntax code. The 
25 syntax level code may then be compiled using a standard compiler, or modified at 
the syntax level and converted back to a visual flowchart representation. At any 
point, the flowchart byte-code represents the target application accurately enough 
that it is always able to be compiled, hence satisfying the requirement for 
flowchart to syntax level code conversion. • 

30 

[055] Because the code modifi-^i by a programmer cannot, however, be 
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guaranteed to be correct, a traditional parsing algorithm must be used to first 
verify the code prior to attempting to represent it as byte-code (viz. Figure 1). 

[056] Once the programmer-modified code has been accurately converted back to 
5 byte-code, a flowchart visualisation can be readily re-drawn, or the byte-code may 
be converted to machine level instructions. The process can be used iteratively, 
until the programmer decides to output a set of machine level instructions thereby 
completing the application. 



10 



15 



[057] In the interests of simplicity, the final program can be converted back to 
byte-code, either transparently or deliberately, so that a standard compiler can be 
used to convert the program to machine code. However, as the program is, by 
definition, able to be compiled at this stage, the total compile time is significantly 
reduced. 



[058] Figure 3 illustrates the complete process for the present embodiment of a 
bi-direction programming language. 



20 



[059] The following Table I shows basic byte-code language for use in the 
preferred embodiment. 



Byte 


Construct 


Byte Code Length 
(bytes) 


1 


Assignment 


4 


2 


Method Call 


3 + 1 byte per 
parameter 


3 


If Expression 


Variable according to 
expression, but min 4 
bytes 


4 


If/Else Expression 


Variable according to 
expression, but min 5 
bytes 


5 


For loop 


1 + composition of 3 
sub-expressions (2 
assignments and If 
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Byte 


Construct 


Byte Code Length 
(bytes) 






condition) 


6 


Repeat Clause 


2 bytes + If condition 


7 


Do/While Clause 


2 bytes + If condition 




Switch/Case 
Expression 


If condition for start + 
1 byte per case. 


8 




(Nb. Each case task 
can be viewed as a 
nested block, 
expressible by a 
single procedure call). 


9 


End Block 


1 



Table I - Basic Byte Code Language. 



[060] Table I provides a definition for a byte-code language that can graphically 
5 describe a basic visual language. Using this table as the data model of a 
traditional Document/Model/View program abstraction, a programmer can 
graphically represent the pseudo-code for any application. 

[061] In a particular embodiment, a software implementation of the present 
10 invention expands this byte-code, to graphically represent the semantic 
components of a defined expression. However, using the sample byte-code, this 
level of abstraction would need to be provided using traditional top-down parser 
logic (refer to figure 1). 

15 [062] Presented in figures 4 to 9 is an illustrative example of an embodiment of 
the invention in use. The example is intended to be merely illustrative and not 
limiting to the scope of the present invention. This example is presented as a 
series of steps which refer to the figures. 

Step 1 : (Figure 4) Using a system or program embodiment of the 
20 present invention as an application program development environment the 

initial flowchart representation is created by selecting icons, which 
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represent programming constructs, from a tool bar (not shown), selecting 
variables from a graphical 'Variable Manager* module (not shown), and 
entering parameters in response to prompts. 

Step 2: (Figure 5) The user selects a * Generate Java and View 
5 Source' menu option (not shown), and the equivalent Java code is 

generated. 

Step 3: (Figure 6) The Java code can then be modified by a 
programmer, by inserting additional code or making changes to the code. 
In this example, an addition has been made following the marker 
10 "//Inserted Code", 

Step 4: (Figure 7) Transparently to the end user, the development 
system or program converts the code to a byte-code equivalent. 

Step 5: (Figure 8) The equivalent flowchart representation, .now 
reflecting the alteration to the Java code made by the programmer at syntax 
15 level, is generated and displayed. 

Step 6: (Figure 9) From the modified flowchart, corresponding Java 
code can again by generated and viewed. Note that the "//Inserted Code", 
marker is no longer present as the code now exactly matches the flowchart 
from which it was created. Of course, the option exists to graphically 
20 modify the flowchart in figure 8 prior to re-generating the Java code, in 

which case the generated code would reflect any changes made at the 
graphical flowchart level. 



[063] A particular embodiment of the present invention can be realised using a 
25 processing system, an example of which is shown in figure 10. In particular, the 
processing system 10 generally includes at least a processor 11, a memory 12, an 
input device 13 and an output device 14, coupled together via a bus 15. An 
external interface 16 can also be provided for coupling the processing system 10 
to a storage device 17 which houses a database 18. The memory 12 can be any 
30 form of memory device, for example, volatile or non- volatile memory, solid state 
storage devices, magnetic devices, etc. The input device 13 can include, for 
example, a keyboard, pointer device, voice control device, etc. The output device 
14 can include, for example, a display device, monitor, printer, etc. The storage 

17 
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device 17 can be any form of storage means, for example, volatile or non- volatile 
memory, solid state storage devices, magnetic devices, etc, 

[064] In use, the processing system 10 is adapted to perform various functions, 
5 such as execute application programs, perform computer readable instructions, 
convert between data types, compile or parse code, and allow data or information 
to be stored in and/or retrieved from the database 17 or information source via a 
network. The processor 11 receives instructions via the input device 13 and 
displays results to a user via the output device 14. It should be appreciated that 
•10 the processing system 10 may be any form of processing system, such as a 
computer terminal, server, specialised hardware, personal computer (PC), mobile 
data terminal, portable computer, personal digital assistant (PDA), or any other 
similar type of electronic device. 

15 [065] A further alternative embodiment of the invention involves replacing the 
flowchart data structure with that of a conventional parse tree. The parse tree is 
generally used in language processing to de-compile the meaning of a sentence 
based on the grammatical make-up. For example, the English sentence "Jane sees 
Spot run" could be represented by the parse tree illustrated in Figure 11. 

20 

[066] Conventionally, a parse tree is created by a compiler to represent the data 
structure that defines the meaning of a given block of code. On creation of the 
parse tree, the parser may reach error states as indicated in the simple parse 
algorithm shown in Figure 1. These error states may or may not affect the 

25 creation of the parse tree. For example, semantic errors such as the referencing of 
a variable that has not been previously declared, can cause the tree to lack 
sufficient meaning to be able to generate a final program. Syntactic errors, such 
as the failure to terminate a statement with the appropriate symbol, usually a fiiU 
stop in every day language, or unbalanced parenthesis in a mathematical formula, 

30 will cause sufficient disruption so that a parse tree cannot be created. According 

to this particular embodiment of the invention, neither situation poses a 

significant problem. By manipulating the tree nodes graphically, it can be 
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guaranteed that syntactic errors do not occur. Similarly, although it is important 
to the dynamics of building a piece of software, that semantic errors are allowed 
to occur from time to time, it is still possible to block other operations within a 
software tool embodying the invention until such time as these errors have been 
5 rectified. The challenge then turns to how this is controlled when manipulating 
the source code in a conventional editor. 

[067] By employing an incremental compilation strategy, the parse tree can be 
generated "on the fly" as the programmer types code. This tool strategy is 
10 currently used by code editors that implement a feature known as "syntax hi 
lighting" to assist the programmer. However, where such tools leave any errors 
either syntactic or semantic simply marked in red, it is essential for the purpose of 
bi-directional programming, that syntactic errors be treated much more severely. 

15 [068] Unfortunately, given that a parse tree cannot be created when a syntactic 
error occurs, it is largely impossible to detect the exact location of such an error. 
For this reason, the strategy that has been taken is to block a number of the tool 
features until such time as the error has been corrected. Examples of features that 
would be blocked, are the option to compile, or translate the view back to a 

20 graphical view and hence manipulate the project in a graphical mode. The parse 
trees for corresponding to figures 6 and 9 are represented in figures 12 and 13 
respectively. 

[069] Thus, there has been provided in accordance with the present invention, a 
25 bi-directional programming system or method for assisting a programmer to 
develop programs which satisfies the advantages set forth above. 

[070] The invention may also be said broadly to consist in the parts, elements 
and features referred to or indicated in the specification of the application, 
30 individually or collectively, in any or all combinations of two or more of said 
parts, elements or features, and where specific integers are mentioned herein 
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which have known equivalents in the art to which the invention relates, Buch 
known equivalents are deemed to be incorporated herein as if individually set 
forth. 

5 [071] Although the preferred embodiment has been described in detail, it should 
be understood that various changes, substitutions, and alterations can be made 
herein by one of ordinary skill in the art without departing from the spirit or 
scope of the present invention. 
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